REMARKS 

This Amendment is filed in response to the Office Action 
dated April 14, 2005, which has a shortened statutory period set 
to expire July 14, 2005. A two-month extension is requested 
herewith, thereby extending the deadline for response to 
September 14, 2005. 

Double Patenting Rejection 

Claims 1-4, 6-14, and 16-20 stand rejected under the 
judicially created doctrine of obviousness -type double patenting 
as being unpatentable over Claims 1-18 of Zhong. Claims 3 and 
13 are cancelled, rendering the rejections of those claims moot. 
A terminal disclaimer is filed herewith, thereby overcoming the 
rejections of Claims 1-2, 4, 6-12, 14, and 16-20. Note that 
this terminal disclaimer is submitted for the purpose of 
advancing prosecution of the instant application, and is not an 
acknowledgement of the validity of the underlying obviousness - 
type double patenting rejections . 

Rejections Under 35 U.S.C, 102 

Claims 1-4, 6-7, 11-14, and 16-17 stand rejected under 35 
U.S.C. 102(b) as being anticipated by York. Claims 3 and 13 are 
cancelled, rendering the rejections of those claims moot. 
Applicants respectfully traverse the rejections of Claims 1-2, 
4, 6-7, 11-12, 14, and 16-17 in light of the foregoing 
amendments and the following remarks. 

Claim 1, as amended, recites in part: 

[S]pecifying at least one hardware description 
language object that represents at least one signal as a 
symbol in a design using a first statement that is part of 
a hardware description language; and 

instructing a symbolic simulator in response to the 
first statement to treat the at least one hardware 
description language object as a symbol. (Emphasis added.) 
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Support for this amendment is found in the specification as 
originally filed at least at page 11, lines 3-10, and page 12, 
line 9 through page 14, line 8. Claims depending from Claim 1 
are amended as needed to maintain consistency with amended Claim 
1. No new matter is added. 

[S] pecifying ... [a] hardware description language object 
that represents at least one signal as a symbol in a design 
using a first statement" as recited in Claim 1, beneficially 
allows ''the existing hardware description languages ... to 
support the specification of symbolic input." (Specification, 
page 11, lines 9-11.) As a result, "a symbolic simulator [can] 
in response to the first statement . . . treat the at least one . 
hardware description language object as a symbol" as recited by 
Claim 1, thereby eliminating the need for the user to manually 
specify the signal during the simulation. 

In contrast, York explicitly describes a methodology in 
which the user must ''take the Verilog simulation, apply symbolic 
boolean variables to the inputs of the receivers in both 
descriptions, and simulate symbolically". (York, page 14, 
section 3.3, emphasis added.) Thus, in the methodology of York, 
symbolic inputs must be supplied at the start of the symbolic 
simulation. None of the cited portions of York disclose or 
suggest "specifying at least one hardware description language 
object that represents at least one signal as a symbol in a 
design" (emphasis added) as recited by Claim 1. 

For example, Figure 2 of York is cited by the Office Action 
as supporting the rejection of Claim 1 under 35 U.S.C. 102(b) . 
However, Figure 2 of York (duplicated here for reference) merely 
depicts a standard Verilog code sample for an ALU. Therefore, a 
listing of various case choices (i.e., "out = a 8c b" , "out = a 
I b" , "out = a + b" , and "out = a - b" ) is included. Applicants 
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assume that the citation of this figure of York by the Office 
Action is due to the presence of these expressions. 



Verilog 


IF 


module aUi (out» ^ b, mode); 
output [4:0) out; 
iopui 13:01 a, b: 
input f 1:0] mode: 
iegl4t0] out; 

always @(a or b or mode) 
case(fno^f 1 :01) 

2*bOI roui^alb; 
2'bin:oui = a + b; 
2*btl :oui«a-b; 
endcase 
endrntHFule 


MODULE nlu (out, a. b» mode) 
iNPtrr Diode : army ! 0 of boolean; 
INPUT a : array 3 Oof bootean; 
INPinr b : airay 3 0 of boolean; 
OUTPUT out : airay 4 0 of boolean; 

out :=((nKxic =0)7(0 ::a&b): 
{{mode«l)?(0::alb): 
((mode=i 2)?a + b: 
a-b))); 



Figure 2t Veritog sind correspondiiig IF 



However, the case choices in Figure 2 of York are explicit 
expressions of the output values for a given mode, and therefore 
do not ''represent [] at least one signal as a symbol ... using a 
first statement that is part of a hardware description language" 
(emphasis added) as recited by Claim 1. Nowhere does York 
describe or suggest code that "specif [ies] at least one hardware 
description language object that represents at least one signal 
as a symbol" as recited by Claim 1, and consistently, neither 
does York describe or suggest ''instructing a symbolic simulator 
... to treat the at least one hardware description language 
object as a symbol" (emphasis added) , as further recited by 
Claim 1. 

Thus, for at least these reasons. Claim 1 is allowable 
under 35 U.S.C. 102(b) over York. Claims 2, 4, 6, and 7 depend 
from Claim 1, and are therefore allowable over York for at least 
the same reasons that Claim 1 is allowable. Accordingly, 
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Applicants respectfully request reconsideration and allowance of 

Claims 1, 2, 4, 6, and 7. 

Claim 11, as amended, recites in part: 

[E]xecutable instructions which . . . cause the at least 
one processing device to: 

specify at least one hardware description 
language object that represents at least one signal as 
a symbol in a design using a first statement that is 
part of a hardware description language; and 

instruct a symbolic simulator in response to the 
first statement to treat the at least one hardware 
description language object as a symbol. (Emphasis 
added . ) 

Support for this amendment is found in the specification as 
originally filed at least at page 11, lines 3-10, and page 12, 
line 9 through page 14, line 8. Claims depending from Claim 11 
are amended as needed to maintain consistency with amended Claim 
11. No new matter is added. 

Thus, for substantially the same reasons as described above 
with respect to Claim 1, Claim 11 is allowable under 35 U.S.C. 
102(b) over York. Claims 12, 14, 16, and 17 depend from Claim 

11, and are therefore allowable over York for at least the same 
reasons that Claim 11 is allowable. Accordingly, Applicants 
respectfully request reconsideration and allowance of Claims 11, 

12, 14, 16, and 17. 

Rejections Under 35 U.S.C. 103 

Claims 9-10 and 19-20 stand rejected under 35 U.S.C. 103(a) 
as being unpatentable over York in view of Dawson. However, 
Dawson merely describes the ''Verilog Procedural Interface [, 
which] is a new C-programming interface for the Verilog Hardware 
Description Language" (Dawson, page 17, abstract), and does not 
remedy the deficiencies of York described above with respect to 
Claims 1 and 11. Claims 9-10 depend from Claim 1, and Claims 
19-20 depend from Claim 11. Therefore, Claims 9-10 and 19-20 
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are allowable under 35 U.S.C. 103(a) over York in view of 
Dawson . 

Accordingly, Applicants respectfully request 
reconsideration and allowance of Claims 9-10 and 19-20. 
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CONCLUSION 



Claims 1, 2, 4, 6-12, 14, and 16-20 are pending in the 
present Application. Reconsideration and allowance of these 
claims is respectfully requested. 

If there are any questions, please telephone the 
undersigned at (408) 451-5903 to expedite prosecution of this 
case . 



I hereby certify that this correspondence is being deposited 
with the United States Postal Service as FIRST CLASS MAIL in 
an envelope addressed to: Mail Stop Amendment, Commissioner 
for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on 

September 14, 2005. 




Respectfully submitted, 



Customer No. : 35273 



Attorney for Applicant (s) 
Reg. No. 45,984 
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